Method and system for detailed accounting of packet data

ABSTRACT

A method and apparatus for detailed accounting of packet data are disclosed. According to one embodiment of the present invention, on receiving a duplicated HTTP request from a packet duplication apparatus, a billing apparatus extracts an access address to generate a first hash value. Then, on receiving a converted HTTP response from the packet duplication apparatus, the billing apparatus extracts a second hash value from the duplicated HTTP response to compare with the first hash value. If the first hash value and the second hash value are the same, the billing apparatus sets the HTTP REQUEST and the converted HTTP response as a transaction to generate billing data. Thus, the billing apparatus can generate accurate billing data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S.application Ser. No. 11/269,279, filed Nov. 8, 2005, which is acontinuation application, and claims the benefit under 35 U.S.C. §§ 120and 365 of PCT Application No. PCT/KR2005/000649, filed on Mar. 9, 2005and published on Sep. 15, 2005, in English, which is hereby incorporatedby reference. PCT/KR2005/000649 also claimed priority from Korean PatentApplications Nos. 10-2004-0027336 and 10-2004-0027337 both filed on Apr.21, 2004 and 10-2004-0015705 filed on Mar. 9, 2004, all of which arehereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to method and system for detailedaccounting of packet data, more particularly, a method and system fordetailed accounting of packet data for use of mobile data services.

2. Description of the Related Technology

Recently, it is possible to transceive a voice signal and a high-speeddata in a mobile terminal due to wireless communication technology suchas code division multiple access (CDMA).

A user can receive data via a packet network, and a mobile communicationservice provider generates billing data at every time of using a packetnetwork (use of mobile data services) for service charges and managesgenerated billing data. Total service charges corresponding to each dataservice use and voice service use are calculated by aggregating thegenerated billing data at a predetermined period of time (e.g.,monthly).

Thus, to make a reliable service charge to a user, the mobilecommunication service is presenting ways for guaranteeing thetransparency of service charges.

The following is a conventional method of generating billing data foruse of mobile data services.

First, in order to receive a content data from a content server, a usersends a data request to a packet data serving node (PDSN) where themobile terminal accesses.

The PDSN sends the data request to one of proxy servers corresponding tothe service platform of the mobile terminal (e.g., binary runtimeenvironment for wireless (BREW), mobile explorer (ME), KTF unifiednavigator (KUN), wireless Internet platform for interoperability (WIPI)and video on demand (VOD), etc.). In sending the data request to theproxy server, a billing apparatus calculates a network usage chargecorresponding to the data request.

The proxy server sends the data request to a corresponding contentserver and receives content data from the content server and transmitsit to the PDSN. Also, the billing apparatus calculates a content usagecharge and network usage charge in this process.

The PDSN sends received content data to the mobile terminal, and thebilling apparatus sums up the network usage charges and/or content usagecharges to generate a combined billing data or to perform a billingprocess.

In the conventional method of generating billing data as describedabove, the billing apparatus generates the billing data at every time oftransmitting a packet data (e.g., data request, content data) betweenthe PDSN and the proxy server.

Namely, when a user requests content transmission to the content serverby a hyper text transfer protocol (HTTP) protocol via a wired/wirelessInternet and/or other network, the billing for the content transmission(i.e., network usage charges, content usage charges) is performed beforechecking whether or not the mobile terminal receives requested contentdata.

This method of generating billing data is based on the assumption thatthe network and the content server operate in an ideal communicationenvironment. Thus, instability of the network and malfunction of thecontent server can cause billing errors.

That is, since the conventional method generates billing data byanalyzing a TCP/IP protocol only, it is impossible to generate billingdata commensurate with the use history of mobile data services of auser. Furthermore, even if a HTTP protocol analysis is performed, it isalso impossible to generate an accurate billing data because theconventional method generates billing data based on an assumption thatthere must exist a pair of HTTP request and HTTP response, i.e.,transaction.

Also, the conventional method generates billing data, even if the userdoes not receive any data (e.g., communication error, data absence,etc), only because there is a HTTP request.

Also, it is difficult to recognize the transaction by locating a networkanalyzer for a network packet between the mobile terminal and the proxyserver in the conventional method.

Also, there is a problem that the conventional method generates anInternet protocol detail record (IPDR) based on the amount of used timeand used packet for a whole data session when generating billing datasuch as an IPDR or call detail record (CDR)). Namely, an IPDR forindividual services used in the same data session is not generated.

Also, there is another problem that the conventional method cannotgenerate an accurate IPDR when a repeated transaction, an unfinishedtransaction or unfinished session happens.

SUMMARY OF CERTAIN INVENTIVE ASPECTS

One aspect of the invention provides a method and system for detailedaccounting of packet data, which generates billing data after finishingtransmission of content data so that reliable billing data can begenerated.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can check if data transmissionis completed normally by analyzing packet transmitted between a mobileterminal and a content server.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can prevent an occurrence ofthe billing error.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which share Hash function in mobilecommunication service system to recognize transaction easily.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can provide the detailed andrigid billing for Internet service and content through the transactionrecognition.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can recognize transactionbased on network packet or HTTP message in communicating HTTP requestmessage and HTTP Response message between the mobile terminal and theproxy server by using persistent connection.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can perform detailedaccounting for each service by generating IPDR combining time billingdata and packet billing data of each service being used in same session.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can generate accurate IPDReven if repeated transaction, unfinished transaction or unfinishedsession happens.

Another aspect of the present invention provides a method and system fordetailed accounting of packet data, which can distinguish packettransmission time and idle time in same data session and apply aseparate billing policy to the idle time.

Still another aspect of the present invention provides a method ofdetermining a billing time for a billing apparatus to generate billingdata for using a mobile data service, comprising: i) acquiring an ACKnumber (Acknowledgement number) included a HTTP Response thatcorresponds to the HTTP Request and is transmitted from the contentserver to the user terminal as a first parameter, ii) acquiring acontent-length field value included in the HTTP Response as a secondparameter, iii) acquiring a header length that is calculated from a TCPpayload of a first packet of the HTTP Response as a fourth parameter,iv) acquiring an ACK number included in an ACK message that correspondsto the HTTP Response and is transmitted from the user terminal to thecontent server as a fourth parameter, v) determining whether or not thefourth parameter is not less than a fifth parameter that is a sum of thefirst parameter, the second parameter and the third parameter, and vi)generating billing data if the fourth parameter is not less than thefifth parameter.

In one embodiment, a generation of billing data is deferred until a newACK message including the fifth parameter equal to or larger than thesixth parameter is transmitted from the user terminal to the contentserver if the fifth parameter is less than the sixth parameter. In oneembodiment, the HTTP Request and the HTTP Response are TCP packet data.

In one embodiment, the header length is generated by calculating octetsize from the start of TCP payload of the first packet of HTTP Responseto the first blank line. In one embodiment, the blank line comprisesonly CRLF in one line

In one embodiment, the first parameter is a serial number indicating thefirst octet of the HTTP Request, wherein the second parameter is aserial number indicating the first octet of the HTTP Response. In oneembodiment, the billing apparatus is located on a transmission linebetween the user terminal and the content server, wherein the HTTPRequest and the HTTP Response transceived through the billing apparatus.

In one embodiment, the billing apparatus receives duplicated datacorresponding to the HTTP Request and the HTTP Response from a packetduplication apparatus locating on a transmission line between the userterminal and the content server.

Still another aspect of the present invention provides a method ofdetermining a billing time for a billing apparatus to generate billingdata for using mobile data service, comprising: i) acquiring an ACKnumber (Acknowledgement number) included a HTTP Response thatcorresponds to the HTTP Request and is transmitted from the contentserver to the user terminal as a first parameter, a content-length fieldvalue included in the HTTP Response as a second parameter, a headerlength that is calculated from a TCP payload of a first packet of theHTTP Response as a third parameter, iii) acquiring an ACK numberincluded in an ACK message that corresponds to the HTTP Response and istransmitted from the user terminal to the content server as a fourthparameter, iv) determining whether or not the fourth parameter is notless than a fifth parameter that is a sum of the first parameter, thesecond parameter and the third parameter, and v) generating billing dataif the fourth parameter is not less than the fifth parameter.

Still another aspect of the present invention provides a method ofrecognizing a transaction for billing apparatus, comprising: i)receiving a duplicated HTTP Request from a packet duplication apparatus,wherein the duplicated HTTP Request is duplication data of a HTTPRequest being transmitted from a user terminal to a proxy server via thepacket duplication apparatus and is duplicated by the packet duplicationapparatus, ii) extracting an access address from the duplicated HTTPRequest, iii) generating a first hash value by using the access addressand a predetermined Hash function, iv) receiving a duplicated HTTPResponse from the packet duplication apparatus, wherein the duplicatedHTTP Response is duplication data of a converted HTTP Response beingtransmitted from a content server to the user terminal via the packetduplication apparatus and is duplicated by the packet duplicationapparatus, v) extracting a second hash value from the duplicated HTTPResponse, vi) comparing the first hash value with the second hash value,and vii) setting the HTTP Request and the converted HTTP Response as atransaction if the first hash value is identical with the second hashvalue, wherein the transaction is a pair of the HTTP Request and theconverted HTTP Response.

In one embodiment, in order to generate the converted HTTP Responseincluding the second hash value the proxy server performs: receiving theHTTP Request, generating the second hash value by using the accessaddress and the predetermined hash function, transmitting the HTTPRequest to the content server corresponding to the access address,receiving an original HTTP Response corresponding to the HTTP Requestfrom the content server, and generating the converted HTTP Response byinserting the second hash value into a header of the original HTTPResponse. In one embodiment, the access address is URL (Uniform ResourceLocator).

In one embodiment, the converted HTTP Response is transmitted to theuser terminal via a data service apparatus, wherein the data serviceapparatus is one of the following: an IWF (InterWorking Function), aPDSN (Packet Data Serving Node), a SGSN(Serving GPRS Supporting Node),and a GPRS (Gateway GPRS Supporting Node).

Still another aspect of the present invention provides a method ofrecognizing a transaction for billing apparatus, comprising: i)receiving a HTTP Request from a data service apparatus, ii) extractingan access address from the HTTP Request, iii) generating a first hashvalue by using the access address and a predetermined Hash function, iv)transmitting the HTTP Request to a proxy server, v) receiving aconverted HTTP Response from the proxy server, wherein the convertedHTTP Response comprises a second hash value and an original HTTPResponse corresponding to the HTTP Request, vi) extracting the secondhash value from the converted HTTP Response, vii) comparing the firsthash value with the second hash value, viii) setting the HTTP Requestand the converted HTTP Response as a transaction if the first hash valueis identical with the second hash value, wherein the transaction is apair of the HTTP Request and the converted HTTP Response, and ix)transmitting the converted HTTP Response to the data service apparatus.

In one embodiment, in order to generate the converted HTTP Response theproxy server performs: receiving the HTTP Request, generating the secondhash value by using the access address and the predetermined hashfunction, transmitting the HTTP Request to the content servercorresponding to the access address, receiving the original HTTPResponse corresponding to the HTTP Request from the content server, andgenerating the converted HTTP Response by inserting the second hashvalue into a header of the original HTTP Response.

Still another aspect of the present invention provides a method forgenerating a combined billing data by service group at a billingapparatus for using a mobile data service when TCP session is connectedbetween a user terminal and a proxy server, comprising: (a) recognizinga transaction by use of packet data transceived between a data serviceapparatus and a proxy server, wherein the transaction is a pair of aHTTP Request and a HTTP Response corresponding to the HTTP Request, (b)generating a basic IPDR (Internet Protocol Detail Record) bytransaction, wherein the basic IPDR comprises a start time and an endtime of the transaction, an amount of packet data, and an accessaddress, repeating the (a) and (b) until the end of TCP session betweenthe user terminal and the proxy server, generating a combined IPDR fromaggregating a plurality of basic IPDRs by service group corresponding tothe access address.

In one embodiment, the generating combined IPDR comprises: recognizingan end of TCP session, (c) checking an end error in one of transactionsby using the basic IPDR, (d) redefining the start time or the end timeof the transaction if there exists the end error, (e) classifying thebasic IPDR into one of predetermined service groups based on the accessaddress included in the basic IPDR, repeating the (c) to (e) to allbasic IPDRs generated during the connection of TCP session, andgenerating the combined IPDR from aggregating a service use time byservice group, wherein the aggregated service use time is a sum ofdifferences between the end time and the start time of transactions inthe service group.

In one embodiment, the end error is either a first error in which an endof transaction is not recognized or a second error in which when pluraltransactions occur during one TCP session connection, the end time ofpreceding transaction occurs after the start time of followingtransaction

In one embodiment, the redefining the start time or the end time of thetransaction if there exists the end error is to set the end time ofpreceding transaction equal to the start time of following transaction.

In one embodiment, the billing apparatus performs the (a) and the (b) byuse of the packet data if the data service apparatus, the billingapparatus and the proxy server are located on a transmission line of thepacket data.

In one embodiment, the billing apparatus performs the (a) and the (b) byuse of the packet data being duplicated by the packet duplicationapparatus if the data service apparatus, the packet duplicationapparatus and the proxy server are located on a transmission line ofpacket data and the packet duplication apparatus and the billingapparatus are coupled each other independently. In one embodiment, theaccess address is URL (Uniform Resource Locator).

In one embodiment, the method for generating a combined billing data byservice group further comprises the steps of: calculating a totalservice use time of the user terminal during the TCP session connection,calculating a connection time of the TCP session, calculating an idletime by subtracting the total service time from the connection time ofTCP session, and billing the service use time and the idle time,respectively.

In one embodiment, the calculating a connection time of the TCP sessionis calculating the connection time of TCP session by subtracting a starttime of TCP session from an end time of TCP session if the end time ofTCP session is recognized, calculating the connection time of TCPsession by subtracting the start time of TCP session from an end time ofPPP connection if the end of TCP session is not recognized but the endtime of PPP connection is recognized, calculating the connection time ofTCP session by subtracting the start time of TCP session from an endtime of final transaction of the TCP session connection if the end timeof TCP session connection and the end time of PPP connection are notrecognized.

In one embodiment, the data service apparatus is one of the following:IWF (InterWorking Function), PDSN (Packet Data Serving Node), SGSN(Serving GPRS Supporting Node), and GPRS (Gateway GPRS Supporting Node).

Still another aspect of the present invention provides a billingapparatus for determining a billing time to generate billing data forusing mobile data service, comprising: i) a parameter collector foracquiring a sequence number included in a HTTP Request that istransmitted from a user terminal to a content server as a firstparameter, an ACK number (Acknowledgement number) included a HTTPResponse that corresponds to the HTTP Request and is transmitted fromthe content server to the user terminal as a second parameter, acontent-length field value included in the HTTP Response as a thirdparameter, a header length that is calculated from a TCP payload of afirst packet of the HTTP Response as a fourth parameter, and an ACKnumber included in an ACK message that corresponds to the HTTP Responseand is transmitted from the user terminal to the content server as afifth parameter, ii) a header-length calculator for generating theheader length of the HTTP Response, iii) a comparator for determiningwhether or not the fifth parameter is not less than a sixth parameterthat is a sum of the first parameter, the second parameter, the thirdparameter and the fourth parameter, and iv) a billing data generator forgenerating the billing data if the fifth parameter is not less than thesixth parameter.

In one embodiment, the billing apparatus is located on a transmission ofpacket data between the user terminal and the content server, whereinthe HTTP Request and the HTTP Response transceived through the billingapparatus.

In one embodiment, the billing apparatus receives a duplicated datacorresponding to the HTTP Request and the HTTP Response from a packetduplication apparatus locating on a transmission line between the userterminal and the content server.

Yet another aspect of the present invention provides a billing apparatusto recognize a pair of packet data transceived between a user terminaland a content server, comprising: i) means for receiving a duplicatedHTTP Request and a duplicated HTTP Response from a packet duplicationapparatus, wherein the duplicated HTTP Request is duplication data of aHTTP Request being transmitted from the user terminal to a proxy servervia the packet duplication apparatus and the duplicated HTTP Response isduplication data of a HTTP Response being transmitted from the contentserver corresponding to an access address to the user terminal via thepacket duplication apparatus, and the HTTP Request and the HTTP Responseare duplicated by the packet duplication apparatus, ii) means forextracting the access address from the duplicated HTTP Request, iii)means for generating a first hash value by using the access address anda predetermined Hash function, iv) means for extracting a second hashvalue from the duplicated HTTP Response, v) means for comparing thefirst hash value with the second hash value, and vi) means for settingthe HTTP Request and the converted HTTP Response as the transaction ifthe first hash value is identical with the second hash value, whereinthe transaction is a pair of the HTTP Request and the converted HTTPResponse, wherein in order to generate the converted HTTP Responseincluding the second hash value the proxy server performs: receiving theHTTP Request, generating the second hash value by using the accessaddress and the predetermined hash function, transmitting the HTTPRequest to the content server corresponding to the access address,receiving an original HTTP Response corresponding to the HTTP Requestfrom the content server, and generating the converted HTTP Response byinserting the second hash value into a header of the original HTTPResponse.

Yet another aspect of the present invention provides a billing apparatusto recognize a pair of packet data transceived between a user terminaland a content server, comprising: i) means for receiving a HTTP Requestfrom a data service apparatus and a converted HTTP Response from theproxy server, ii) means for extracting an access address from the HTTPRequest, iii) means for generating a first hash value by using theaccess address and a predetermined Hash function, iv) means forextracting a second hash value from the converted HTTP Response, v)means for comparing the first hash value with the second hash value, vi)means for setting the HTTP Request and the converted HTTP Response as atransaction if the first hash value is identical with the second hashvalue, wherein the transaction is a pair of the HTTP Request and theconverted HTTP Response, and vii) means for transmitting the HTTPRequest to a proxy server and the converted HTTP Response to the dataservice apparatus, wherein in order to generate the converted HTTPResponse including the second hash value the proxy server performs:receiving the HTTP Request, generating the second hash value by usingthe access address and the predetermined hash function, transmitting theHTTP Request to the content server corresponding to the access address,receiving an original HTTP Response corresponding to the HTTP Requestfrom the content server, and generating the converted HTTP Response byinserting the second hash value into a header of the original HTTPResponse.

Yet another aspect of the present invention provides a billing apparatusfor generating billing data for using a mobile data service during TCPsession connection between a user terminal and a proxy server,comprising: a recognizing part for recognizing a transaction by use ofpacket data transceived between a data service apparatus and a proxyserver, wherein the transaction is a pair of a HTTP Request and a HTTPResponse corresponding to the HTTP Request, a basic IPDR generating partfor generating a basic IPDR (Internet Protocol Detail Record) bytransaction, wherein the basic IPDR comprises a start time and an endtime of the transaction, an amount of packet data, and an accessaddress, and a combined IPDR generating part for generating a combinedIPDR from aggregating a plurality of basic IPDRs by service groupcorresponding to the access address.

In one embodiment, the combined IPDR generating part comprises: asession manager for recognizing an end of TCP session, a checking partfor checking if there is an end error in one of transactions by usingthe basic IPDR, an error correcting part for redefining the start timeor the end time of the transaction if there exists the end error, atransaction classifying part for classifying the basic IPDR into one ofpredetermined service groups based on the access address included in thebasic IPDR, and a use time aggregating part for generating the combinedIPDR from aggregating service use times by service group, wherein theaggregated service use time is a sum of differences between the end timeand the start time of transactions in the service group.

In one embodiment, the billing apparatus further comprises an idle timecalculating part for generating an idle time by subtracting a totalservice use time from a connection time of TCP session.

In one embodiment, if the end error is either a first error that an endof transaction is not recognized or a second error that when pluraltransactions occur during one TCP session connection, the end time ofpreceding transaction occurs after the start time of followingtransaction, the error correcting part sets the end time of thetransaction equal to the start time of following transaction.

Yet another aspect of the present invention provides a computer-readablemedium including a program containing computer-executable instructionsfor performing the method for generating a combined billing data byservice group at a billing apparatus, comprising: (a) recognizing atransaction by use of packet data being transmitted between a dataservice apparatus and a proxy server, wherein the transaction is a pairof a HTTP Request and a HTTP Response corresponding to the HTTP Request,(b) generating a basic IPDR (Internet Protocol Detail Record) bytransaction, wherein the basic IPDR comprises a start time and an endtime of the transaction, an amount of packet data, and an accessaddress, repeating the (a) and (b) until the end of TCP session betweenthe user terminal and the proxy server, generating a combined IPDR fromaggregating a plurality of basic IPDRs by service group corresponding tothe access address, recognizing an end of TCP session, (c) checking anend error in one of transactions by using the basic IPDR, (d) redefiningthe start time or the end time of the transaction if there exists theend error, (e) classifying the basic IPDR into one of predeterminedservice groups based on the access address included in the basic IPDR,repeating the (c) to (e) to all basic IPDRs generated during theconnection of TCP session, and generating the combined IPDR fromaggregating service use times by service group, wherein the aggregatedservice use time is a sum of differences between the end time and thestart time of transactions in the service group.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of mobile communication service systemaccording to one embodiment of the present invention.

FIG. 2 is a block diagram of a mobile communication service systemaccording to another embodiment of the present invention.

FIG. 3 is a data flowchart for determining the time to generate billingdata at the billing apparatus.

FIG. 4 shows a conventional structure of a TCP segment.

FIG. 5 is a data flowchart for determining the time to generate billingdata at the billing apparatus according to another embodiment of thepresent invention.

FIG. 6 is a flowchart for recognizing a transaction in mobile dataservice according to another embodiment of the present invention.

FIG. 7 is a flowchart for recognizing a transaction in mobile dataservice according to another embodiment of the present invention.

FIG. 8 is a flowchart of method for generating combined billing data foreach service according to another embodiment of the present invention.

FIG. 9 shows the use flow of mobile data service according to anotherembodiment of the present invention.

FIG. 10 is a flowchart of method for eliminating errors when thecombined IPDR is generated according to another embodiment of thepresent invention.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

Embodiments of the present invention will be described with accompanyingdrawings. Throughout the whole drawings, same reference numbers will beused to refer to the same elements.

FIG. 1 is a block diagram of mobile communication service systemaccording to one embodiment of the present invention.

Referring to FIG. 1, a mobile communication service system 120 comprisesa BTS (Base Transceiver Station) 125, a data service apparatus 130, apacket duplication apparatus 135, a billing apparatus 140, and a proxyserver 145. Although not shown in FIG. 1, the mobile communicationservice system 120 can further comprise a BSC (Base Station Controller),a MSC (Mobile Switching Center), a HLR (Home Location Register), a VLR(Visitor Location Register), etc.

The BTS 125 enables a mobile communication between the user terminal 110and the mobile communication service system 120 via a mobile network,and communicates signals with the data service apparatus 130 on atransmission line. The user terminal 110 accesses to the mobilecommunication service system 120 via a mobile network, receives contentdata (e.g., ring sound, wallpaper, moving picture, etc.) from severalcontent servers (150 a, 150 b, . . . , 150 n: hereinafter, referred as‘150’) being coupled to the mobile communication service system 120. Theuser terminal 110 is, for example, one of mobile terminal, PDA (PersonalDigital Assistant), notebook computer, etc.

The data service apparatus 130 enables the use of mobile Internetservice, and is, for example, one of IWF (InterWorking Function), PDSN(Packet Data Serving Node), SGSN(Serving GPRS Supporting Node), and GPRS(Gateway GPRS Supporting Node). IWF is the mobile data service apparatusused in 2G network, PDSN is the mobile data service apparatus insynchronous 3G network, and GPRS is the mobile data service apparatus inasynchronous 3G network. Of course, it is apparent that any apparatushaving same function described above will be used in embodiments of thepresent invention.

The packet duplication apparatus 135 duplicates all kinds of packet databeing transceived between the data service apparatus 130 and the proxyserver 145 to deliver duplicated packet data to the billing apparatus140.

The billing apparatus 140 determines whether or not the transmission ofcontent according to the user's request is normally completed (e.g.,HTTP Response corresponding to HTTP Request is transmitted to the userterminal 110) by using packet data from the packet duplication apparatus135, and in case of normal transmission, generates billing datacorresponding to the use of mobile data service and performs billing.

The billing apparatus 140 comprises an analyzing part for checking ifcontent data transmission is normally completed and a billing part forgenerating billing data and for performing billing.

The billing apparatus 140 recognizes the transaction (a pair of HTTPRequest/Response) for determining the normal completion of content datatransmission. Hash function can be used for recognizing transaction. Theway of recognizing transaction by using Hash function in the billingapparatus 140 will be described with accompanying drawing.

Also, the billing apparatus 140 generates basic IPDR for eachtransaction by using packet data received from the packet duplicationapparatus 135, and aggregates basic IPDRs according to the predeterminedrule (e.g., by service type) to generate combined IPDR. The billingapparatus 140 performs billing by using the basic IPDR and/or combinedIPDR.

The proxy server 145 consists of plural servers corresponding to serviceplatforms of the user terminal 110 (e.g., BREW, ME, KUN, WIPI, VOD, andso on), and receives content data from the content server 150corresponding to service platform. Namely, the proxy server 145 performsrelay of content data, protocol conversion, encryption and so on.

On receiving a mobile data service request from the user terminal 110,the proxy server 145 transmits menu data corresponding to service itemsavailable at the content server 150 corresponding to the user terminal'sservice platform to the user terminal 110. Also, on receiving a HTTPrequest from the user terminal 110, the proxy server 145 receivescontent data from the content server and transmits the received contentdata to the user terminal 110 via the data service apparatus 130. HTTPRequest is one of content data request and content data upload request,however, hereinafter assume that HTTP Request is the content datarequest.

Also, the proxy server 145 further generates Hash value by using URL ofHTTP Request from the user terminal 110, and inserts the generated Hashvalue into the header of HTTP Response (content data can be comprised)being received from the content server 150 to transmit to the userterminal 110.

The content server 150, which is coupled to the mobile communicationservice system 120 via a mobile network and provides content datarequested by the user, is one of a ring sound providing server, awallpaper providing server, a stock information providing server and soon.

As shown in FIG. 1, one TCP session between the user terminal 110 andthe proxy server 145 is set up in the mobile communication service suchas GPRS (General Packet Radio Service), CDMA-2000 (Code DivisionMultiple Access-2000), WCDMA (Wideband CDMA). Thus, though a user sendsHTTP Requests to plural content servers 150, all HTTP Requests are sentto corresponding content servers 150 via the proxy server 145. Also, allHTTP Responses from plural content servers 150 are transmitted to theuser terminal 110 via the proxy server 145.

Namely, in case that the user terminal 110 receives content data fromplural content servers 150, plural TCP sessions separated by eachcontent server 150 or each service are set up, and service type for eachsession is changed in the mobile communication service environment. Asthis, the mobile communication service environment is totally differentfrom the conventional wired Internet environment.

Thus, the billing apparatus 140 for extracting packet between the userterminal 110 and the proxy server 145 detects usage data for plural webservices in one TCP session, not plural TCP sessions being distinguishedby the type of content server 150 or service type.

FIG. 2 is a block diagram of the mobile communication service systemaccording to another embodiment of the present invention.

As shown in FIG. 2, the mobile communication service system 120comprises the billing apparatus 140 being located between the dataservice apparatus 130 and the proxy server 145. Thus, the packetduplication apparatus 135 can be omitted.

The billing apparatus 140 checks if content data transmission iscompleted normally by using packet data transceived between the dataservice apparatus 130 and the proxy server 145, and in case of normalcompletion, generates billing data for the usage of mobile data service.

Of course, it is apparent that any configuration, that can check ifcontent data transmission is completed by using packet data communicatedbetween data service apparatus 130 and the proxy server 145 and generatebilling data, may be applied without limitation.

FIG. 3 is a data flowchart for determining the time to generate billingdata at the billing apparatus, and FIG. 4 shows TCP segment structure.

FIG. 3 shows the method for determining the time to generate billingdata that is used for the billing apparatus 140 to determine thecompletion of HTTP-based content transmission in the state that TCPsession between the user terminal 110 and the content server 150 is setup by TCP handshaking.

Referring to FIG. 3, at step 310, the user terminal 110 designatescontent to be received in the form of URL by use of HTTP GET method andtransmits to the content server. HTTP GET method attaches information tothe URL. It is apparent that the HTTP Response is transmitted to thecontent server 150 via the data service apparatus 130 and the proxyserver 145 so that detailed description will be omitted here.

At step 310, the billing apparatus 140 acquires HTTP GET method and URLfrom the TCP packet that is corresponding to the HTTP requesttransceived between the data service apparatus 130 and the proxy server145. Also, the billing apparatus 140 acquires a sequence number assignedto the TCP packet as a parameter (hereinafter, “J value”), and ACK(Acknowledgement) number as a parameter (hereinafter, “K value”). Where,J value is a serial number representing the first octet of HTTP Request,K value is a serial number representing the first octet of HTTPResponse.

Hereinafter, TCP segment format is described with FIG. 4.

TCP segment is a basic unit that is transmitted by TCP (TransmissionControl Protocol). TCP segment is divided into TCP header and data, andTCP header comprises a fixed header of 20 bytes and an option field.

Source port and destination port are port numbers designatingapplication programs on each end-side of TCP connection.

Sequence number designates where data in the segment locates in bytestream of the application program.

Acknowledge number is a response of a receiver for the segment from asender, and designates byte number of segment to be received.

Header length is an integer value and designates how many 32-bit wordsare included.

Window size designates size of available buffer of a receiver, and flowcontrol between each end is performed.

Checksum is for detecting error in TCP segment and the rear part of 12bytes of IP header.

Urgent pointer designates where urgent data locates.

Referring FIG. 3 again, at step 315, the content server 150 transmitsTCP ACK message to the user terminal 110. TCP ACK message indicates thatthe content server received HTTP Request. The step 315 can be omitted.

After performing process corresponding to HTTP Request being receivedfrom the user terminal 110, the content server 150 generates HTTPResponse to the user terminal at step 320. At this time, TCP sequencenumber of the first packet of HTTP Response is K value. And, HTTPResponse header in TCP packets having K value as sequence number amongpackets, that the content server 150 transmitted to the user terminal110, has a content length field. According to HTTP specification, thecontent length field must indicate an accurate size of message body ofHTTP Response. Thus, at step 320, the billing apparatus 140 can acquirethe content length field value as a parameter (hereinafter, “L value”).Also, the billing apparatus 140 calculates an octet size from the startof TCP payload of the first packet to the first blank line (only CRLFexists on one line) of HTTP Response to acquire a parameter(hereinafter, “M value”).

The content server 150 can transmit HTTP Response consisting of morethan one IP packet to the user terminal 110. When receiving HTTPResponse, the user terminal 110 can transmit ACK messages to the contentserver at intervals before HTTP Response is completed (step 325, 330).

At step 330, the billing apparatus 140 keeps checking ACK messages,which are transmitted from the user terminal 110 to the content server150, to acquire ACK number as a parameter (hereinafter, “Y value”).

At step 335, the billing apparatus 140 checks that sum of K value, Lvalue, M value is less than Y value. Namely, if Y value is equal to orhigher than the sum, the billing apparatus 140 determines that HTTPResponse that the content server 150 intended to transmit is transmittedto the user terminal 110 normally, and starts to generate billing data.But, if Y value is less than the sum, the billing apparatus goes back tothe step 330 to acquire Y value.

As described above, the billing apparatus 140 acquires ACK number (Kvalue) included in HTTP Request at step 310, and content length (Lvalue) in HTTP Response and header length (M value) of HTTP header atstep 320. And, at step 330, the billing apparatus 140 acquires ACKnumber (Y value) of TCP ACK message. When Y value is equal to or higherthan the sum of K value, L value and M value, the billing apparatus 140determines that the transmission of content is completed and performsbilling.

But, if Y value is less than the sum, the billing apparatus 140determines that the transmission of content is not completed and candefer billing. Also, if TCP session is released even when Y value isless than the sum, the billing apparatus determines that thetransmission of content is failed and performs billing corresponding tothe failure. Also, it is possible to generate no billing data. Also,since the message body does not exists in HTTP Response for HTTP Requestincluding HEAD method or HTTP Response including HTTP Response code suchas 1 xx, 204, 304, the billing apparatus 140 regards that these messagesare not a billing target. It is because the content is not transmittedin this case. For reference, HEAD method does not allow to include anydata in the message body of HTTP Response. Informational 1 xx means atemporary response. Response code 204 is used when although the contentserver received HTTP Request, there is no data to be transmitted.

Also, if there is no Content-length field and there is Transfer-codingfield instead of identity field in HTTP Response, the billing apparatus140 can perform a process by replacing Content-length value withTransfer-length value.

FIG. 5 is a data flowchart for determining the time to generate billingdata at the billing apparatus according to another embodiment of thepresent invention.

FIG. 5 shows an actual packet data transmission procedure between a userterminal 110 and a content server 150 when the user access to a contentserver (i.e., groups.google.com) 150 via the mobile communicationservice system 120. But, only packet data relating to embodiments of thepresent invention among packet data to be transceived between the userterminal 110 and the content server 150 at TCP level will be described.

Referring to FIG. 5, the user terminal 110 and the content server 150set up TCP session through transmission of TCP packet at step 510through 520.

At step 525, the user terminal 110 transmits HTTP Request to the contentserver 150. HTTP Request includes URL corresponding to‘http://groups.google.com/index.html’. And, the billing apparatus 140acquires sequence number ‘1’ in HTTP Request as J value and ACK number‘1’ as K value.

At step 530, the content server 150 can transmit ACK message having Jvalue as ACK number to confirm the receipt of HTTP Request to the userterminal 110.

At step 535, the content server 150 starts to transmit HTTP Response tothe user terminal 110. The billing apparatus 140 receives HTTP Responseto be transmitted to the user terminal from the content server 150, andacquires Content-length value ‘2709’ in header of HTTP Response as Lvalue. Also, the billing apparatus 140 calculates Header-length toacquire the calculated header length ‘168’ as M value.

Then, TCP segments can be transmitted to the user terminal 110 from thecontent server 150 continuously (step 540). When TCP ACK message istransmitted to the content server 150 from the user terminal 110, thebilling apparatus 140 acquires ACK number of the TCP ACK message, whichis transmitted from the packet duplication apparatus 135, ‘2878’ as Yvalue (step 545).

At step 550, the billing apparatus 140 checks whether or not the contentis normally transmitted from the content server 150 to the user terminal110 by comparing a sum of K value, L value and M value with Y value.And, if the content transmission is completed normally, then the billingapparatus starts billing. Namely, if Y value is equal to or higher thanthe sum, then the transmission of content is regarded as normalcompletion. In the data flow in FIG. 5, Y value(‘2878’) and thesum(‘2878) of K value(‘1’), L value(‘2709’) and M value(‘168’) are equalso that the billing apparatus determines that the transmission ofcontent is completed normally. And, the billing apparatus 140 performsbilling by using basic billing data such as a size of content includedin HTTP Response, a network usage time, and so on. Of course, it isapparent that conventional method or any method to be developed forgenerating billing data can be used in the billing apparatus 140 withoutany limit.

And, when applying a method for comparing Y value with the sum of Kvalue, L value and M value to the content server 150, it is alsopossible for the content server 150 to check whether or not the contentis transmitted to the user terminal 110 normally. Thus, if it is notconsidered as a normal transmission, the content server 150 canretransmit the content.

FIG. 6 is a flowchart for recognizing a transaction in mobile dataservice according to another embodiment of the present invention.

Referring to FIG. 6, at step 610, the user terminal 110 transmits HTTPRequest for a content selected by user to the proxy server 145 vianetwork. HTTP Request is delivered to the proxy server 145 via BTS 125,the data service apparatus 130, the packet duplication apparatus 135,and so on.

At step 615, the billing apparatus 140 receives the duplicated HTTPRequest from the packet duplication apparatus 135, and extracts URL fromthe HTTP Request. And, the billing apparatus 140 generates the firsthash value by use of the extracted URL and the predetermined Hashfunction. If the Hash function for generating the first hash value isidentical with the Hash function for generating the second hash value inthe proxy server 145, any suitable Hash function can be used inembodiments of the present invention. In one embodiment, the Hashfunction includes MD5, SHA-1, HAS-160, and so on. Since parameters andmethod for generating hash value by using Hash function are well knownin the art, detailed description will be omitted.

At step 620, the proxy server 145 receives HTTP Request from the userterminal 110, and extracts URL from HTTP Request. And, the proxy server145 generates the second hash value by use of the extracted URL and thepredetermined Hash function. The Hash function used by the proxy server145 must be identical with the Hash function used by the billingapparatus 140.

At step 625, the proxy server 145 transmits HTTP Request from the userterminal 110 to the corresponding content server 150.

Then, the proxy server 145 at step 630 receives original HTTP Responseincluding content data corresponding to HTTP Request (e.g., stockinformation request) from the content server 150.

Since the proxy server 145 can recognize that the original HTTP Responseat step 630 corresponds to which one of HTTP Requests, the proxy server145 inserts the second hash value as a new field value into the headerof original HTTP Response header to generate a converted HTTP Responseat step 635. There is no limit to the newly-inserted field name for theproxy server 145 to insert the second hash value into the original HTTPResponse if the newly-inserted field name is not identical with a fieldname that is already used between the user terminal 110 and the proxyserver 145 or the user terminal 110 and the content server 150.

And, the proxy server 145 at step 640 transmits the converted HTTPResponse to the user terminal 110 via network. At this time, theconverted HTTP Response is transmitted to the user terminal 110 via thepacket duplication apparatus 135, the data service apparatus 130, BTS125, and so on.

At step 645, the billing apparatus 140 receives the converted HTTPResponse that the packet duplication apparatus 135 duplicated, andextracts the second hash value from the header field of the convertedHTTP Response. In order for the billing apparatus 140 to extract thesecond hash value, the field name for the second hash value must beshared with the proxy server 145 and the billing apparatus 140.

At step 650, the billing apparatus 140 determines whether or not thefirst hash value generated at step 615 and the second hash valueextracted at step 645 are identical. If identical, the billing apparatus140 at step 655 recognizes that converted HTTP Response is the responseof HTTP Request transmitted at step 610. Namely, HTTP Request andconverted HTTP Response are regarded as a pair. But, if not identical,the billing apparatus 140 regards HTTP Request and converted HTTPResponse as different messages and ends the step. Of course, the step645 through 655 can be repeated until receiving the converted HTTPResponse corresponding to HTTP Request.

For example, if the user terminal 110 transmits the first HTTP Requestand the second HTTP Request to the proxy server 145, the billingapparatus 140 generates the first hash value for the first duplicatedHTTP Request received from the packet duplication apparatus 135 and thesecond hash value for the second HTTP Request.

And, the proxy server 145 transmits the first HTTP Request and thesecond HTTP Request to the corresponding content servers 150,respectively. And, during this procedure, the third hash value and thefourth hash value corresponding to the first HTTP Request and the secondHTTP Request respectively are generated and stored.

When receiving original HTTP Response from the content server 150, theproxy server 145 determines that the original HTTP Response correspondsto which one of the first HTTP Request and the second HTTP Request. And,the proxy server 145 generates the converted HTTP Response by insertingcorresponding hash value into the header of the original HTTP Response.And, the proxy server 145 transmits the converted HTTP Response to theuser terminal 110.

The billing apparatus 140 receives the converted HTTP Response from thepacket duplication apparatus 135, and extracts the hash value from theheader of the converted HTTP Response. The billing apparatus 140determines that the extracted hash value corresponds to which one of thefirst hash value and the second hash value and recognizes the convertedHTTP Response as a pair of HTTP Request corresponding to the hash value.

If two sequential HTTP Requests (i.e., the first HTTP Request and thesecond HTTP Request) for same URL are transmitted from the user terminal110 to the proxy server 145, all hash values generated by the billingapparatus 140 and the proxy server 145 may be identical. In this case,the time sequence of each HTTP Request cannot be distinguished by usinghash values. But, in case of same URL, two HTTP Responses (i.e., thefirst converted HTTP Response and the second converted HTTP Response)for tow HTTP Requests are actually same at HTTP message level so thatthe billing apparatus 140 can perform HTTP pair matching regardless ofarriving order of HTTP Request and HTTP Response.

Also, although HTTP Responses that are transmitted from the contentserver 150 as responses for plural HTTP Requests for same URL may bedifferent from each other, this case happens only when the networkbetween the user terminal 110 and the content server 150 is unstable.

FIG. 7 is a flowchart for recognizing a transaction in mobile dataservice according to another embodiment of the present invention.

The flowchart in FIG. 7 shows the method for recognizing transactionwhen the billing apparatus 140 locates between the data serviceapparatus 130 and the proxy server 145 as shown in FIG. 2. Namely, FIG.7 shows the method for recognizing HTTP Request/Response when packetdata being transceived between the user terminal 110 and the contentserver 150 always goes through the billing apparatus 140.

Referring to FIG. 7, at step 710, the billing apparatus 140 receivesHTTP Request for any content from the user terminal 110. The billingapparatus 140 at step 715 transmits the received HTTP Request to theproxy server 145. And, at step 720, the billing apparatus 140 generatesthe first hash value by using URL included in the HTTP Request and thepredetermined Hash function. Of course, the order of step 715 and 720can be changed.

The billing apparatus 140 at step 725 receives the converted HTTPResponse from the proxy server 145, and transmits the converted HTTPResponse to the user terminal 110. As the method for generating theconverted HTTP Response at the proxy server is same to the method asalready described in FIG. 6, same description is omitted.

At step 730, the billing apparatus 140 extracts the second hash valuefrom the header of the converted HTTP Response received at the step 725.At step 735, the billing apparatus determines whether or not the firsthash value at step 720 and the second hash value at step 730 areidentical. If identical, the billing apparatus recognizes the convertedHTTP Response as a response of HTTP Request at step 715. Namely, HTTPrequest and the converted HTTP Response are recognized as a pair. But,if not identical, HTTP Request and the converted HTTP Response arerecognized as separate ones and the step is ended. Of course, the step725 to step 740 can be repeated until the converted HTTP Responsecorresponding to the HTTP Request is received. Also, the step oftransmitting the converted HTTP Response to the user terminal 110 can beperformed after finishing the step 730 to 740 by using the convertedHTTP Response.

FIG. 8 is a flowchart of method for generating combined billing data foreach service according to another embodiment of the present invention,FIG. 9 shows the use flow of mobile data service according to anotherembodiment of the present invention, and FIG. 10 is a flowchart ofmethod for eliminating errors when the combined IPDR is generatedaccording to another embodiment of the present invention.

Referring to FIG. 8, the billing apparatus 140 at step 810 receivesduplicated packet data from the packet duplication apparatus 135, andgenerates basic IPDR by a transaction at step 815. As above described,the packet duplication apparatus 135 can be removed. In one embodimentof the present invention, transaction is a pair of HTTP Request andcorresponding HTTP Response transceived between the user terminal 110and the proxy server 145 in one TCP session. Basic IPDR comprises eachstart time and end time of transaction (e.g., start time and end time ofHTTP Request, start time and end time of HTTP Response), a size ofpacket data composing the transaction, an access address of the contentserver 150 (e.g., all lists of URL used for each transaction), userinformation, a termination reason of Internet use (e.g., normaltermination, abnormal termination), and so on.

There is no limit on which method the billing apparatus 140 uses forrecognizing transaction. But, two methods for the billing apparatus 140to recognize the transaction will be described for the purpose ofunderstanding.

First, it can be used to recognize the transaction that the billingapparatus 140 and the proxy server 145 generate each hash value by usingsame Hash function, respectively, and then the billing apparatus 140checks that the generated hash values are identical each other. Ofcourse, the procedure of recognizing transaction by hash value matchingcan be performed by an additional data analyzing apparatus (not shown),and the billing apparatus 140 can generate basic IPDR by a transactionby using the transaction recognition result of the data analyzingapparatus.

Hereinafter, the method for recognizing transaction by hash valuematching will be described in brief.

When the user terminal 110 transmits HTTP Request for any content, theHTTP Request is delivered to the proxy server 145 via the data serviceapparatus 130, the packet duplication apparatus 135, and so on. Thebilling apparatus 140 (or data analyzing apparatus) receives theduplicated HTTP Request from the packet duplication apparatus 135, andextracts URL from the duplicated HTTP Request. And, the billingapparatus 140 generates the first hash value by using the extracted URLand the predetermined Hash function (e.g., MD5, SHA-1, HAS-160, and soon). The proxy server 145 extracts URL from the HTTP Request, andgenerates the second hash value by using the extracted URL and thepredetermined Hash function. The proxy server 145 transmits the HTTPRequest to the corresponding content server 150, and receives originalHTTP response including content data corresponding to the HTTP Requestfrom the content server 150. Since the proxy server 145 can recognizethat the original HTTP Response corresponds to which HTTP Request, theproxy server 145 inserts the second hash value corresponding to the HTTPRequest into a new field of the header of the original HTTP Response togenerate the converted HTTP Response. And, the proxy server 145transmits the converted HTTP Response to the user terminal 110 vianetwork, and during this step, the packet duplication apparatus 135duplicates the converted HTTP Response to transmit it to the billingapparatus 140. The billing apparatus 140 extracts the second hash valuefrom the header field of the converted HTTP Response, and determineswhether or not the first hash value and the second hash value areidentical each other. If identical, the converted HTTP Response and HTTPRequest corresponding to the first hash value are recognized as a pair.The packet duplication apparatus 135 can be removed as aforementioned.

Next, when receiving HTTP Response corresponding to HTTP Request, theproxy server 145 can insert billing data for the HTTP Request and HTTPResponse into HTTP Response to transmit to the data service apparatus130. If using this method, the billing apparatus 140 receives duplicatedpacket data of HTTP Response including billing data from the packetduplication apparatus 135, and performs the transaction recognition andbilling by using the duplicated packet data.

The method for the proxy server to recognize transaction and generatingbilling data by changing header data of HTTP Response will be describedin brief.

When the user terminal 110 transmits HTTP Request for any content, theHTTP Request is delivered to the proxy server 145 via the data serviceapparatus 130, the packet duplication apparatus 135, and so on. Theproxy server 145 transmits the HTTP Request to the corresponding contentserver 150, and receives original HTTP response including content data(e.g., stock information request) corresponding to the HTTP Request fromthe content server 150. The proxy server 145 extracts HTTP header datafrom the original HTTP Response, and inserts basic billing data intoHTTP header data to generate the converted HTTP Response. Basic billingdata is, for example, one of the number of bytes of HTTP Request, thenumber of bytes of HTTP Response, an access address of the contentserver 150, user information, and so on. Since the proxy server 145manages HTTP information including session information about receivingHTTP Request for which content data from the user terminal 110 andtransmitting the HTTP Request to which content server 150, basic billingdata can be easily inserted into HTTP header. Then, the proxy server 145transmits the converted HTTP Response to the user terminal 110 via thepacket duplication apparatus 135, the data service apparatus 130, and soon. The packet duplication apparatus 135 duplicates the converted HTTPResponse to transmit it to the billing apparatus 140. The billingapparatus 140 performs billing for the transaction by using basicbilling data inserted into the header of the converted HTTP Response.Since basic billing data comprises the number of bytes of HTTP Request,the number of bytes of HTTP Response, the access address of contentserver 150, and so on, it is not needed for the billing apparatus 140 toperform additional billing for HTTP Request and HTTP Response. Also,since the proxy server 145 performs to compose the transaction, it ispossible to perform billing only if there exists normal HTTP Response.

Of course, there may be many methods for recognizing transaction (a pairof HTTP Request and HTTP Response) in the billing apparatus 140. And,hereinafter assume that the billing apparatus 140 recognizes a pair ofHTTP Request and HTTP Response and composes a transaction.

At step 820, the billing apparatus 140 classifies basic IPDR generatedat step 815 into service groups. FIG. 9 shows the use flow of mobiledata service of user. A mobile service provider can classify variousservices into plural service groups (e.g., service group classificationbased on URL) according to its service plan. Hereinafter, assume that ifdomain name of access address (e.g., URL) is same then it will beregarded as same service group. And, assume that the use flow of mobiledata service in FIG. 9 shows the case that user uses mobile dataservices which belong to plural service groups such as service group A,service group B and service group C.

The billing apparatus 140 at step 825 aggregates basic IPDRs classifiedby a service group to generate combined IPDR, and performs billing byuse of time data of TCP session and IPDR at step 830.

Hereinafter, with referring to FIGS. 9 and 10, the procedure ofgenerating the combined IPDR and performing billing will be described indetail. As described above, FIG. 9 is a use flow of the mobile dataservice that user uses plural services (i.e., service group A, servicegroup B and service group C) in one TCP session connected between theuser terminal 110 and the proxy server 145. The method for generatingthe combined IPDR will be described with the use flow of the mobile dataservice in FIG. 9 and the flowchart in FIG. 10 even if the network isunstable or the user terminal operates abnormally.

Referring to FIG. 10, at step 1010, the billing apparatus 140 determineswhether or not an end time of PPP connection t_(end) is recognized. Ift_(end) is recognized, t_(FIN) is set up at step 1015. But, if t_(end)is not recognized, the end time of last transaction before end of TCPsession t_(end) is set up as t_(C2). Generally, start time of PPPt_(start) and end time of PPP t_(end) can be recognized with highprecision in the mobile communication service system 120. Also, thebilling apparatus 140 can recognize start time of TCP session t_(syn).But, packet for recognizing t_(FIN) cannot be generated or t_(FIN)cannot exist (e.g., t_(FIN) expands to infinity) due to the instabilityof network or malfunction of the user terminal 110.

At step 1025, the billing apparatus 140 finds error-occurred transactionamong transactions that were generated during the connected TCP session.The billing apparatus 140 can determine the following cases as end errorof transaction: the end of any transaction is not recognized, or the endof any transaction is recognized after start of next transaction. If noend error, the billing apparatus goes to step 1035. Generally, tosatisfy the condition of no error among plural transactions in TCPsession, the use flow of the mobile data service must satisfy thecondition as shown in Table 1.

TABLE 1 Conditions of normal end of transaction transaction Start timeEnd time Relation 1st transaction (710) t_(a1) t_(a2) t_(syn) ≠ t_(a1)2nd transaction (720) t_(b1) t_(b2) t_(a2) ≠ t_(b1) 3rd transaction(730) t_(a3) t_(a4) t_(b2) ≠ t_(a3) 4th transaction (740) t_(b3) t_(b4)t_(a4) ≠ t_(b3) 5th transaction (750) t_(a5) t_(a6) t_(b4) ≠ t_(a5) 6thtransaction (760) t_(c1) t_(c2) t_(a6) ≠ t_(c1)

Additionally, the condition that use time of TCP session is not same tothe total use time of each transaction must satisfy“t_(FIN)−t_(syn)−service group A use time (i.e.,(t_(a2)−t_(a1))+(t_(a4)−t_(a3))+(t_(a6)−t_(a5)))+service group B usetime (i.e., (t_(b2)−t_(b1))+(t_(b4)−t_(b3)))+service group C use time(i.e., (t_(c2)−t_(c1)))”. This means that there generally exists idletime between each transaction.

But, if there is an end error, the end time of transaction is redefinedat step 1030. At first, if end of any transaction of TCP session is notrecognized, the start time of next transaction will be regarded as theend time of the transaction. For example, if the end of the thirdtransaction 930 is not recognized, the end time t_(a4) of transaction930 will be the start time of the fourth transaction 940 t_(b3).

Next, if any transaction ends after a next transaction started, the endtime of the transaction will be redefined as the start time of the nexttransaction according to the billing policy. For example, if the firsttransaction 910 ends after the start time t_(b1) of the secondtransaction 920, the end time t_(a2) of the first transaction 910 can beredefined as the start time t_(b1) of the second transaction 920.

Then, at step 1035, the billing apparatus 140 aggregates use time ofeach service. Namely, the billing apparatus 140, as described above,classifies each transaction into corresponding service groups, andaggregates use time of classified transactions of each service group.

Also, at step 1040, the billing apparatus 140 calculates idle time. Theidle time means time that TCP session is connected but not occupied byany transaction (i.e., t_(IDLE)=(t_(FIN)−t_(syn)−(service group A usetime+service group B use time+service group C use time)).

At step 1045, the billing apparatus 140 performs billing for service use(i.e., data service use time and content usage charge) and thecalculated idle time. Since the billing apparatus according to oneembodiment of the present invention can calculate the service use timeand idle time with high precision, it is possible to perform anoptimized billing for the mobile data service use. Namely, oneembodiment of the present invention can solve the problem of chargingthe idle time with high rate.

In describing the method for generating combined billing data for eachservice till now, we mainly described the method that classifies pluraltransactions during the TCP session into service groups based on theaccess address and then aggregates use time of plural transactions ofsame service group to perform billing. Namely, it was assumed thatcharge for use time (i.e., network usage charge) or content usage chargeper service group is applied equally.

But, in some cases, although transactions are included in the sameservice groups, only network usage can be charged to one transaction(e.g., content data search service), or network usage and content usagecan be charged to another transaction (e.g., content download service).

Also, although transactions are generated in one TCP session, onetransaction can be charged according to use time, or another transactioncan be charged according to amount of packet use.

But, it is apparent that the aforementioned method for aggregatingtransaction according to service group can be applied to these cases. Inthis case, for example, it will be enough to equip a detailed servicegroup (e.g., time billing service, packet billing service, content usagebilling service, etc.) subordinated to a service group that isdetermined by URL, so detailed description will be omitted. Of course,it is also apparent that various methods for classifying service groupscan be applied for charging mobile data service use according to variousservices having different charges.

Until now, we, mainly described the system of generating combinedbilling data for each service with the packet duplication apparatus 135.And, in this case, the billing apparatus 140 generated basic IPDR andcombined IPDR by using duplicated packet data transmitted from thepacket duplication apparatus 135 (referring FIG. 1). But, as shown inFIG. 2, the packet duplication apparatus can be removed, and withoutpacket duplication apparatus, the billing apparatus 140 can generatebasic IPDR and combined IPDR by similar way. Namely, the billingapparatus 140 generates basic IPDR and combined IPDR by using packetdata that goes through itself. If the packet duplication apparatus 135is not included, since it is apparent for those skilled in the art toconstruct the method of billing apparatus 140 for generating IPDR withease, detailed description will be omitted.

As described above, embodiments of the present invention can generatereliable billing data by generating billing data after finishing thetransmission of content data. Furthermore, embodiments of the inventioncan provide the following advantages.

One embodiment of the present invention can easily check if datatransmission is completed normally by analyzing packet transceivedbetween the mobile terminal and the content server.

Another embodiment of the present invention can prevent an occurrence ofthe billing error, and can share a Hash function in mobile communicationservice system to recognize transaction easily.

Another embodiment of the present invention can provide the detailed andrigid billing for Internet services and contents through the transactionrecognition.

Another embodiment of the present invention can recognize transactionbased on network packet or HTTP message in communicating HTTP requestmessage and HTTP Response message between the mobile terminal and theproxy server by using persistent connection.

Another embodiment of the present invention can perform detailedaccounting for each service by generating IPDR combining time billingdata and packet billing data of each service being used in same session.

Still another embodiment of the present invention can generate accurateIPDR even if repeated transaction, unfinished transaction or unfinishedsession happens.

Still another embodiment of the present invention can distinguish packettransmission time and idle time in same data session and apply aseparate billing policy to the idle time.

While the above description has pointed out novel features of theinvention as applied to various embodiments, the skilled person willunderstand that various omissions, substitutions, and changes in theform and details of the device or process illustrated may be madewithout departing from the scope of the invention. Therefore, the scopeof the invention is defined by the appended claims rather than by theforegoing description. All variations coming within the meaning andrange of equivalency of the claims are embraced within their scope.

1. A method of generating billing data for use of mobile data services,the method comprising: obtaining an acknowledgement (ACK) numberincluded in a hyper text transfer protocol (HTTP) response thatcorresponds to a HTTP request and is transmitted from a content serverto a user terminal as a first parameter; obtaining a content-lengthfield value included in the HTTP response as a second parameter;obtaining a header length that is calculated from a transmission controlprotocol (TCP) payload of a first packet of the HTTP response as a thirdparameter; obtaining an ACK number included in an ACK message thatcorresponds to the HTTP response and is transmitted from the userterminal to the content server as a fourth parameter; determiningwhether or not the fourth parameter is equal to or greater than a fifthparameter that is a sum of the first parameter, the second parameter andthe third parameter; and generating billing data if the fourth parameteris equal to or greater than the fifth parameter, wherein the headerlength is generated by calculating an octet size from the beginning of aTCP payload of the first packet of a HTTP response to the first blankline of the first packet.
 2. The method in claim 1, further comprisingdeferring a generation of the billing data until a new ACK message,including the fourth parameter equal to or greater than the fifthparameter, is transmitted from the user terminal to the content serverif the fourth parameter is less than the fifth parameter.
 3. The methodin claim 1, wherein the HTTP request and the HTTP response are a TCPpacket data.
 4. The method in claim 1, wherein the blank line comprisesonly CRLF in one line.
 5. The method in claim 1, wherein the firstparameter is a serial number indicating the first octet of the HTTPresponse.
 6. The method in claim 1, wherein the billing apparatus islocated on a transmission line between the user terminal and the contentserver, wherein the HTTP request and the HTTP response are transmittedvia the billing apparatus.
 7. The method in claim 1, wherein the billingapparatus receives a duplicated data corresponding to the HTTP requestand the HTTP response from a packet duplication apparatus located on atransmission line between the user terminal and the content server.
 8. Amethod of generating billing data for use of mobile data services, themethod comprising: obtaining an acknowledgement (ACK) number included ina hyper text transfer protocol (HTTP) response that corresponds to aHTTP request and is transmitted from a content server to a user terminalas a first parameter, a content-length field value included in the HTTPresponse as a second parameter, a header length that is calculated froma transmission control protocol (TCP) payload of a first packet of theHTTP response as a third parameter; obtaining an ACK number included inan ACK message that corresponds to the HTTP response and is transmittedfrom the user terminal to the content server as a fourth parameter;determining whether or not the fourth parameter is equal to or greaterthan a fifth parameter that is a sum of the first parameter, the secondparameter and the third parameter; and generating billing data if thefourth parameter is equal to or greater than the fifth parameter,wherein the header length is generated by calculating an octet size fromthe beginning of a TCP payload of the first packet of a HTTP response tothe first blank line of the first packet.
 9. A billing apparatus fordetermining billing data for use of mobile data services, the apparatuscomprising: a parameter collector configured to obtain anacknowledgement (ACK) number included a hyper text transfer protocol(HTTP) response that corresponds to a HTTP request and is transmittedfrom a content server to a user terminal as a first parameter, acontent-length field value included in the HTTP response as a secondparameter, a header length that is calculated from a transmissioncontrol protocol (TCP) payload of a first packet of the HTTP response asa third parameter, and an ACK number included in an ACK message thatcorresponds to the HTTP response and is transmitted from the userterminal to the content server as a fourth parameter; a header-lengthcalculator configured to generate the header length of the HTTPresponse; a comparator configured to determine whether or not the fourthparameter is equal to or greater than a fifth parameter that is a sum ofthe first parameter, the second parameter and the third parameter; and abilling data generator configured to generate the billing data if thefourth parameter is equal to or greater than the fifth parameter,wherein the header length is generated by calculating an octet size fromthe beginning of a TCP payload of the first packet of a HTTP response tothe first blank line of the first packet.
 10. The billing apparatus inclaim 9, wherein the billing apparatus is located on a transmission ofpacket data between the user terminal and the content server, whereinthe HTTP request and the HTTP response are transmitted via the billingapparatus.
 11. The billing apparatus in claim 9, wherein the billingapparatus receives a duplicated data corresponding to the HTTP requestand the HTTP response from a packet duplication apparatus located on atransmission line between the user terminal and the content server. 12.A method of generating billing data for use of mobile data services, themethod comprising: receiving content request data from a user terminalvia a wireless network; providing the request data to a content server;receiving requested content data from the content server; providing therequested content data to the user terminal; determining whether all ofthe content data have been received by the user terminal; and generatingbilling data for the content data if all of the content data have beenreceived by the user terminal, wherein the determining comprises:obtaining an acknowledgement (ACK) number from a hyper text transferprotocol (HTTP) response as a first parameter, wherein the HTTP requestis sent to from the user terminal to the content server and the HTTPresponse is sent from the content server to the user terminal inresponse to the HTTP request; obtaining a content-length field valueincluded in the HTTP response as a second parameter; obtaining a headerlength that is calculated from a transmission control protocol (TCP)payload of a first packet of the HTTP response as a third parameter;obtaining an ACK number included in an ACK message that corresponds tothe HTTP response and is transmitted from the user terminal to thecontent server as a fourth parameter; and determining whether or not thefourth parameter is equal to or greater than a fifth parameter that is asum of the first parameter, the second parameter and the thirdparameter, wherein the billing data is generated if the fourth parameteris equal to or greater than the fifth parameter, and wherein the headerlength is generated by calculating an octet size from the beginning of aTCP payload of the first packet of a HTTP response to the first blankline of the first packet.
 13. A method of determining a billing time fora billing apparatus to generate billing data for using a mobile dataservice, comprising: acquiring a sequence number included in a HTTPRequest that is transmitted from a user terminal to a content server asa first parameter; acquiring an ACK number (Acknowledgement number)included a HTTP Response that corresponds to the HTTP Request and istransmitted from the content server to the user terminal as a secondparameter; acquiring a content-length field value included in the HTTPResponse as a third parameter; acquiring a header length that iscalculated from a TCP payload of a first packet of the HTTP Response asa fourth parameter; acquiring an ACK number included in an ACK messagethat corresponds to the HTTP Response and is transmitted from the userterminal to the content server as a fifth parameter; determining whetheror not the fifth parameter is not less than a sixth parameter that is asum of the first parameter, the second parameter, the third parameterand the fourth parameter; and generating billing data if the fifthparameter is not less than the sixth parameter.
 14. The method in claim13, wherein the first parameter is a serial number indicating the firstoctet of the HTTP request.